なぜ私が議事録を書くのか？あなたが議事録を書く理由について解説
データアナリティクス事業本部＠札幌の佐藤です。 議事録を書くこと好きですか？ 私がまだ入社間もないころによく指示されていた議事録を書くというタスクについて、昔は面白くなく、うまくできない作業で好きではありませんでした。 いまだに好きではありませんが、議事録を書くというタスクの意味についてなんとなく自分の中で腹落ちできていたのがひとつの要因だと思います。 今回は議事録の「書き方」について言及せず、なぜ議事録を自分が書かなきゃいけないのかという側面で明文化していきたいと思います。 あくまで私の経験によるものとなりますので、本来のあるべきからそれている可能性や、違うということもあるかと思いますがご了承いただければと思います。 また、当内容は議事録を取るという仕事をされている方を否定している記事ではありません。
あなたがなぜ議事録を取るのか
議事録を取る人というのは往々にして、その会議に参加している中でロールが一番下の方、もしくは年齢が若い方などが担当することが経験上多いです。 私はプロジェクトマネージャを務めていますが、参加者の中で私が一番低いロールであれば、私が書くことになります。 そういう感じなので、相対的に見て一番下だからという理由で、なんとなく指示を与えている人も多いかなと思います。 理由のない作業にあまり意味がないので、指示を受けた人はなぜ自分がやるんだろうかと思ったりすると思います。 また、新人の人は特に何も知らないのに、なぜ自分がやるのか。技術も要件も知っている人がやるべきなんじゃないかと思うはずです。 私も思っていました。 そのうえで私が新人の人に良く話す理由として、「あなたが何も知らないから」という話をします。 何も知らないからこそ議事録を書かせるのです。
何知らないというのはどういうことか
一般的にIT業界的に「何も知らない」というのは3つに分類されるのかなと思っています。
- お客様の業界用語
- お客様の社内用語
- システム的な用語（サービス固有の言葉や、ITでの一般的な用語含む）
「何も知らない」人は上記1～3全てわからないケースもありますし、1～2がわからないケースがありますが、何かしら分かっていません。 これは新入社員だけではなく、プロジェクトにアサインされる人すべてにおいて1～3を理解している人はいません。 なので、「何も知らない」は別に新入社員に限ったことではなく、みんな分からないのです。 新入社員の人と経験のある人の違いは、キャッチアップする能力が違うということです。 そのキャッチアップする能力をどう身に着けるのかというと、いろいろ手段がありますが、そのひとつに議事録があると考えています。
議事録を取ることで得られる恩恵
個人的には議事録を意識して取ることで、以下が得られるかなと思います。
- 早く案件のキャッチアップができる
- システム的な用語を拾える
- 行間を読む力が養える
1.早く案件のキャッチアップができる
まず、そもそもなぜ議事録をとならければならないのかから話す必要があります。 一般的にお客様との会議は進捗状況の確認、ToDo事項の確認、各課題に対する討議を行う場となります。 会議の最終的なゴールは何らかの合意や、討議結果を両者で共有・納得しあうということです。 議事録はその合意内容の言質を取ることで、後で言った言わないという話を避けるために使います。 つまり会議は、プロジェクトの今の状況を客観的に知れる場であるということです。 議事録はその会議に参加して、自分で文字で書き記しているので、なんとなく今の状況が俯瞰できるということになります。 新入社員の人が、「今の状況を俯瞰できる」ということの重要性に気づくのは、もう少し先かもしれませんが、意味を教えることで納得感はあるはずです。 私が作業者だった頃、特に途中でアサインされた場合は意識的に議事を取るようにしていました。 議事の内容を共有するしないにかかわらずです。 途中でアサインした場合は特に今の状況が見えないため、なんとなくいろいろ問題ありそうだなレベルでも状況をつかめるというのは良かったかなと思います。
2.システム的・業界的な用語を拾える
1と関連する要素にはなりますが、用語が一体何を指しているのかを知れるのは自分の成長機会という点では非常に役立ちます。 新しい案件に入ると、知らない言葉が大量に出てきます。 何も知らない場合はその言葉をまず上の3つの用語の種類のどれなのかを仕分ける必要があります。 知らない用語は人に聞いたり、調べたりすると思いますがその行動によって、自分の頭に理解語彙として残っていきます。 直近の利点としては、その会議での説明で何を話しているのかが、少しわかるようになります。 すこし未来の話を見た場合、そこから関連する書籍を読んだりすることで自分の幅を広げることができます。 （用語だけだとあまりにもピンポイントすぎるので、もう少しそこから根本的なことを書いている資料を読むのがよいと思います） ぼうっと聞いている状態だとその情報は抜け落ちます。 一番近くにある成長できる可能性がある情報を拾わない人と拾う人でどうなることは想像にたやすいかなと思います。
3.行間を読む力が養える
これはプロジェクトマネージャなど上のロールになってくると必要になってくるスキルで、私は議事録をやっていたから身についたかなと思っています。 議事録を取っているときにある「あの人は何を言っているのか」問題です。 日本語特有なのかは分かりませんが、会議では何かしらの情報が欠落している状態で話が展開されます。 今日、オフィスに行きました。 これは誰が？や、どのように？が欠落して伝えられています。 この欠落は何かしらの前提情報がどこかにあり、議事録を書く際にそれを埋めなければならないです。 つまり (誰が)今日、(誰と)(どのように)オフィスに行きました。（なぜなら) と括弧を補記してあげる必要があります。 補記するためには、議事録を取っている会議や、討議議題などの背景を読み取る必要が出てきます。 私含めて皆、5W1Hきちんと書いて文章や口頭で連絡をしません。面倒だからです。 そのため読み取り側がそれを想像、推測していく必要がどうしても出てきます。 それを適切に読み取れるようになるには、議事録での訓練が一番効率がよいと思います。 これができるようになると、普段の生活の中でもおそらく言いたいことはこれかな？という推測ができるようになります。 また推測前提で思考できるので、ある程度の読みができるようになります。 具体的には何かを説明するときに「たぶんこういうことだと思っているから前提でこうしていますよ」というところからスタートできる形になります。 推測が間違っていても、相手が正してくれるケースのほうが多いです。 皆無意識に、推測で考えていることを方を評価しているのだと思います。 オープンクエスチョンするよりは議論が進展しますので、この能力は身に着けたほうがよいです。
どうやって議事録を書けばいいのか
議事録を書くのが苦手な人はまずどうやって議事録を書けばいいのか悩むと思います。 私の経験上、以下4点を意識すると3ヶ月以内である程度できます。 ※私が面倒を見ていた新入社員の人のケースなので、慣れには人それぞれかかる可能性はあります。
- 社内会議など失敗リスクが低いところで練習
- 分からない用語は検索する。それでもわからなかったら人に聞く
- 議事録は会議の実施時間以上使わない
- エンジニアの議事は発言録ではない
1.社内会議など失敗リスクが低いところで練習
関係者がプロジェクトメンバーだけなので、これは単純にできなくても影響範囲が少ないためです。 また自分の作業範囲に一番近い話をしているので、理解がしやすいというのも利点です。 分からないところの質問も比較的自分に近いレビュアーだったりするので、気持ち的にも楽です。 まずはここで率先して議事録を書く、あるいは勝手に議事録を書いていくというのがよいと思います。
2.分からない用語は検索する。それでもわからなかったら人に聞く
ここは「システム的・業界的な用語を拾える」でも言及したところになります。 自分で調べてみて、わからなかったらさらに人に聞くことで自分が理解できていきます。 次に同じ話が出てきたときには既にある程度概要を抑えているため、言葉の括弧を埋めることができるようになります。 言葉の括弧は背景が分からなければ埋めることができないためです。
3.議事録は会議の実施時間以上使わない
議事録は上でも書いた通り、基本的に会議での言質を取っているものです。 言ってしまえば会議で既に決まっていることを後追いで文字起こししているだけなので、会議以上の時間を浪費しているのはエンジニアの本来の役割を考えても無駄といってもいいと思います。 そのため、1時間の会議であれは1時間以内に書くことを守るようにするのがよいです。 ただし、新入社員の人は知らない人が普通の人よりも多いので苦労しています。 指示している人もかつてそうだったと思います。 そのため、指示をしている人は、ある程度時間がかかっていることは考慮してあげて、守ってあげるということも必要です。 経験上、1時間の会議を作るのにレビューバック含め8時間かかった新入社員の人がいましたが、週2回議事録を書くことを続けて、1ヶ月くらいでこのルールを守れるようになったので、自分なりの攻略法を見つけると自然とできるようになるのかなと思います。
4.エンジニアの議事は発言録ではない
結構勘違いしている人がいるなというものです。 私の今までの経験上、発言録レベルで議事を取ったのは大企業の執行役員レベルの人との会議だけです。 それ以外は、話した内容を時系列で書くというよりも、ある程度のテーマのまとまりでグルーピングして書くのが多いです。 会議は往々にして発言した後で、その発言が訂正されるケースがあります。 議事でほしいのは、「最初間違ったことを言っていてその後訂正した」という事実ではなく「訂正して全体で合意した内容」です。 また、話のテーマが行ったり来たりするケースもあります。 エンジニアの議事はあとあと見返したときに、あるテーマに沿って討議されたことが行間を正しく補記された状態で書いてあればよいのです。 なので、話していること全部取らなきゃいけないんだと尻込みしている人は、まずその概念を捨てたほうがいいです。 （私もできなくて速記の勉強をしようと思いました） エンジニアは議事を取る仕事をしているわけではありません。もしそういうものを求めているのであればそれを生業にしている人を呼んだほうがいいです。
レビューをどうするのか
セルフレビューも含め議事録のレビューは非常に難しいです。 私も新入社員のときは、指摘事項に「何言っているか分からない」や「こんなこと言ってる？」みたいな抽象的なことを指摘されていたことを覚えています。 ただこれだと、どう直していいのかよくわからないなとなってしまいます。（なっていました） そのため、私が議事録をセルフレビューやレビューする際は、書いていない括弧を書いてあげるようにしています。 例えば議事録に以下のように書いてレビュー依頼してきた場合、
今日、オフィスに行きました。
ここに括弧を入れていき、指摘する際にこの括弧を埋めてという形で指摘します。 そうすることで指摘事項がはっきりするのと、そこの括弧を埋めようと必死になるので議事録を書く意図を体現してもうことが可能です。
()今日、(と)(で)オフィスに行きました。
みんなで議事録を作るという選択肢もある
議事録を取る人が苦手な人が多く、私の案件はプロジェクト期間も少ないため、議事録で長く時間を確保してあげることが難しいです。 また、現状オンラインでの会議を行っているため、現在は発言していないメンバー複数人で議事録を取る方針としています。
- 討議アジェンダをGoogle Doc等にコピーして共有、みんなで議事が書ける準備をする
- 討議が始まった際、共有されたページで間違ってても、複数人が同じこと書いてもいいから、とにかくみんなで書いていく
- 会議終了後に議事録をまとめる人が発言を整理していく
この方針で、議事録を書かなければいけないという心理的なハードルを下げたり、ある程度発言のぬけ漏れを防ぐことができるということが可能です。
なお、1はSlack上でみんなで書いていくケースもあります。 その場合は、以下リスクがあります。
- 討議アジェンダを書いておかないと、あとから議事録として成形する際にどのアジェンダの話をしていたか見えなくなる。
- 会議中に画面共有している場合、Slackのスッコココが大量に共有画面に表示される可能性がある。
最後に
議事録を書くことに意味があることを説明すると、意外にやってくれたりするので意図を伝えるというのは重要かなと思います。 議事録を書くことが苦手な人や、意味を感じていない人が少しでも参考になれば幸いです。
